In the previous lesson, I mentioned gatekeeper, and if you're at all familiar with McComb's, you'll
most likely already know of it.
In short, gatekeeper as a tool set that validates any new software to make sure it passes all of Apple's
security requirements, including notarization.
So knowing that, before we start the process of notarizing our read it up from the previous section
of the course will first need a way to verify whether it's notarized or not.
To do this, we can use the gatekeeper command line tools.
Again, this is strictly for Mac, just to be clear, over to the terminal where step one is going to
be checking that you do in fact have gatekeeper enabled.
A lot of developers will simply disable gatekeeper from the get go, but of course not.
The average user as gatekeeper is enabled by default to check this, then run pseudo as this requires
route permissions or administrator permissions in Apple terms, SPC, T.L. being the gatekeeper command
line tools with a status flag enter, which prompts you for your password.
So enter that assessment enabled meaning gatekeeper is enabled and checking all new apps.
If you have this disabled, however, you can re-enable it with pseudo spectral master enable in order
to test your notarization and then pseudo spectral master disable to disable it again after should you
wish to do so.
Right.
So knowing gatekeeper's enabled, let's test the redid app we built in the previous section.
Very importantly, you need to test the actual app, not the DMG.
The DMG doesn't ever get notarized, only the app itself.
The app is currently installed on my desktop for the sake of the lessons.
So to assess it, run pseudo spectral with an ISIS flag passing the path to the app.
In my case, home desktop redit dot app enter.
And we get rejected as this app hasn't yet been notarized.
Now, if you're wondering why we didn't get the gatekeeper warning when launching this the first time
in the previous section of the course, that's because it's signed with a developer certificate from
this machine or any other machine and we'd run into issues.
OK, so knowing how to check this, let's go ahead and see how to rebuild each of our Mac targets with
the included step of notarizing them as well.
First up to do this will be using the electron notarised module, this being an official module of the
electron organization account and works perfectly with electron builder.
We can install this as a dev dependency.
So over to the terminal in the project directory NPM install with a D flag for development electron
notarize.
And done then back to the module repo on GitHub, scroll down a bit here, we have some prerequisites
for notarizing an app, the first being to make sure you have the latest version of Xcode, an Apple
developer account, which we knew then to perform.
The notarization with that account will also need an app specific password, which will create in a
minute.
And lastly, the apps need to be signed with a hardened runtime which includes these entitlements.
But note that in pretty much all of the existing tutorials explaining how to notarize an app, this
is still configured manually, including the tutorial link directly from the Electron Balde documentation.
This one here, this used to be the case, but electron balde now default to doing all of this automatically.
A hardened runtime is used to sign all up targets by default and with that the default entitlement with
which electron bould assigns.
Our apps include all of these, including some other useful entitlements like allowing the use of modules
in our app.
So unless you're setting your own entitlements, there's no need to set any of this yourself.
If you would like to read more about what other entitlements you can use or learn more about the hard
and runtime, I've linked to a very detailed breakdown in Apple's developer docs.
OK, so knowing that, let's create this app specific password to use for notarization over to your
Apple ID dashboard at Apple ID dot apple dot com sign in.
And right here in the security section, under specific passwords, generate a new password, giving
this some memorable name, I'll just call it, read it, notarize, create.
And there you'll only be able to see this password once, so copy it and as with the get up personal
access token, I'll write this to a file in the project's private directory in the terminal.
Echo that password as a string to private Apple ID password dot text.
Remember, this entire private directory is excluded from yet another.
Probably better option would be to store it in a password manager like chain or similar.
Then next, we need to configure the electron notary's module to be used by electron builder during
the process.
To do this electron builder provides us a hook with which we can specify a JavaScript function to run
after each target has signed over to packaged JSON, navigate down to the main build configuration setting
after sign, pointing to a JavaScript module which will create in a second.
I'll create this in the build directly.
So bold slash notarised dot js create that script in the directory.
Notarised, James.
There this is where we can now configure notarised Ojai's to handle the entire process for us notat
adding this to your build will add a significant amount of time to the process as each target will be
uploaded to Apple for notarization, something to keep in mind.
You only want to do this for the very final build, not when testing.
OK, so the way the script works then, is that electronical they expect expected to export one default
function?
We can create that as either a node require export or an Essex export.
Doesn't matter which one you choose.
I'll start with a simple message so we can see when the notarization starts in the old log notarizing
up.
And export that one default function with exports, not default.
Equals an asynchronous function.
This function receives one argument from electron Baldor being the context of the target being built.
Now notice that the after sign hook was set in the main build configuration, not in the Mac configuration,
meaning that this will be run for all targets, not just Mac.
So first thing to do in this function is to make sure we are dealing with a Mac up, Skip Notarize,
if not Mac OS checking with F processor platform not equal to Darwin.
Return and if the script doesn't return year, meaning we are building for Mac, continue to notarize,
I'll first get a few variables from this context provided by electron builder assigning to up name context
the single function argument package dot app info, dot product file name.
This is the name of the final up.
So in my case, read it.
We can also get the path where the app is built to assigning to up the context DOT app out there.
We've not yet required electron notarised, so do that right at the start of the script.
Require the notarized function using the structured assignment from the electron notarised module,
that module we installed earlier.
That's all we need.
So next we can run the notarised function and return its response.
Return await as the notarised function returns, a promise which the bold script needs to wait for,
that being why we made this default function asynchronous notarize, this function takes a single argument
being an options object in which we can first set the app bundle ID.
Being this app ID value, we have, in fact, Jason, I'll copy this.
And pist, alternatively, you could also require the package Dargis on file in the script like you
do any other module and access the value on that object, but this will do for now.
Next, set the path.
This tells the notarised script where to find the app that was just signed.
So that will be in the Dyster directly or Abduh this variable year slash app name this variable here
DOT app using an interpolated string, then your Apple developer account idee.
This is usually the email you log into your Apple developer account worth and the Apple ID password,
that app specific password we generated.
Now you could of course just hard code these credentials in the script, but that's not good practice.
So instead will again use some environment variables like we did when setting the get up access token,
setting the Apple ID as process START N.V., DOT, Apple ID and the Apple ID password as process dot
EMV, Apple ID password.
That's all.
The script is now done and ready to use running each time Electron Balde signs a new bould.
We've already verified that the current builders rejected by gatekeeper.
So with all this ready, let's rebuild it for Mac with notarization safe both files and head over to
the terminal.
Delete the entire disk directorate to start afresh.
Running electron builder M for Mac and not forgetting to set those environment variables we are using
in the notarised script, pretending to this command applied equal to my developer email.
And Apple ID password equal to the app specific password we generated, I'll open that file in my editor.
And copied a string.
Which shows us the bold process as before, and now as soon as the signing is complete, we see notarizing
up the loud message from that notarised script.
As mentioned, this can take quite some time depending on your connection.
So I'll skip through this.
And once it's uploaded and notarized, the remainder of the bolt continues as before, forward again
and done.
If anything goes wrong, you'll get some useful output as that promise will be rejected with an error
message.
I'll install the new app from the DMG Mount that.
Overwriting the existing app on my desktop.
Assess the app again.
So over to the terminal.
Pseudo spectacle with a V, this time for verbose SS home desktop, read it, talked up that new one
we just replaced it with, which prompts you for your password.
So enter that.
And if everything went well, you'll now get accepted, meaning this app is notarized and will be allowed
to launch on any Mac without a warning.
That's basically all there is to notarizing Mac apps for self distribution.
But please note that this process can sometimes cause a few issues.
If your app requires special privileges, things like accessing the camera, receiving push notifications,
etc..
So it's still important to test this final version of the app and make sure everything works as expected
if you require any special privileges.
Be sure to take a look at the hard and runtime documentation linked in the lessons resources.
You'll find all the available entitlements there.
And lastly, should you need to verify the entitlements that the app was signed with, you can do so
by running code sign with a D flag, then an entitlements flag.
Colon dash and the path to your app, home desktop, read it.
Which prints the entire entitlements file used to sign this up, just a helpful little addition, should
you need it?
That wraps up notarization again, this might be slightly different for your app, but you should now
have a good understanding of how to handle this process and get your apps out to users.